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For: GENERATING MERGED DOCUMENTS 

Mail Stop AF, Pre- Appeal Conference 
Commissioner for Patents 
P. O. Box 1450 
Alexandria, VA 22313-1450 

ATTACHMENT TO PRE-APPEAL BRIEF REQUEST FOR REVIEW 

I. STATUS OF CLAIMS 

Claims 1-29 and 3 1 are pending. All of the pending claims were rejected under 
35 U.S.C. § 103(a) as allegedly unpatentable over U.S. Patent No. 7,099,027 (hereinafter 
"Barry") in view of U.S. Patent No. 7,202,972 (hereinafter "Schwier"). 

II. THE REJECTIONS ARE BASED ON CLEAR ERRORS 

The rejections of the Final Office Action mailed 1 1 May 2010 ("FOA") are based 
on at least the clear legal and factual errors discussed in the following sections. 

A. CLAIM 1 



1. Neither reference teaches that a merge utility responds to a request to merge 
a document in an original format with a document in a merge format 



Claim 1 recites "receiving, at a merge utility executing on a computer system, a 
request to merge a first merge document in a merge format with a second document in an 
original format." While the original format "is not supported by the output device, and 
therefore needs to be converted to another format that is supported by the output device 
in order to be properly interpreted by the output device," the merge format "is a format 
that is supported by the output device, and therefore does not need to be converted to 
another format that is supported by the output device in order to be properly interpreted 
by the output device." For example, the request may be to merge a document in a word- 
processing format (an example "original format") with a document in a PCL format (an 
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example "merge format"). One or more of the steps of Claim 1 are performed "in 
response to the request" to merge the two documents of different formats. 

The FOA appears to allege that the request recited in Claim 1 is an inherent aspect 
of Schwier' s system. FOA at 3. However, the allegation is clearly legally erroneous, in 
that it is based on nothing more than speculation that "in order to merge the system must 
receive a merge command." Even if Schwier did explicitly teach some form of a "merge 
request" of some form, the FOA still fails to produce any evidence that this "request" is 
the same kind of request as recited in Claim 1 — that is, a "request to merge a first merge 
document in a merge format with a second document in an original format." 

In any event, the allegation is also clearly factually erroneous. In Schwier, no 
entity is ever requested to merge a document in a merge format with a document in an 
original format, within the meanings recited in Claim 1 . Thus, there is no reason why 
Schwier would have implied the request recited in Claim 1. For example, while Variable 
Data 11 and Static Data 12 are merged by Application 10, Schwier at FIG. 2, neither 
Variable Data 1 1 nor Static Data 12 are in a "merge format" as recited by Claim 1. 
Rather, Variable Data 1 1 and Static Data 12 appear to be Office-compatible documents 
such as "a Word document, data blank, [or] an Excel document." Schwier at col. 5, lines 
27-38. Meanwhile, Variable Data 15 and Static Data 16 are merged at the printing 
device 7, Schwier at FIG. 2. Aside from the fact that Claim l's merger does not take 
place at the output device, both Variable Data 15 and Static Data 16 are at the time or 
merger already in PCL format, and therefore the merger does not involve an "original 
format" within the meaning of Claim 1. 

The absence of such a request from the combination of Bany and Schwier is far 
from trivial. One certainly may, as the FOA appears to be alleging, achieve results 
similar to those achieved by Claim 1 by converting an original document to a merge 
document, per Scwhier, and then merging the converted document with another merge 
document, per Barry. However, Applicants are not claiming an end result, but a method 
for achieving a result. Whereas the proposed combination of references would require 
separate requests to separate components in order to accomplish the conversion and 
merger, the method of Claim 1 facilitates the use of a single merge utility to achieve both 
the conversion and the merger. The cited references simply fail to teach or suggest a 
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merge utility whereby one may merge a document in an original format with a document 
in a merge format in response to a request to a single merge utility. 

2. Neither reference features a merge utility that causes a document to be 
converted from an original format to a merge format 

Claim 1 further recites that "in response to the request, the merge utility caus[es] 
the second document to be converted from the original format to the merge format to 
create a second merge document." Neither Barry's nor Schwier' s, alleged merge utilities 
cause an input document to be converted from an original format to a merge format. 

The FOA, at page 3, appears to allege that Schwier teaches such a merge utility 
because, in Schwier, a Word document is eventually converted to a PCL document. 
While Applicants agree that it is clearly well known to convert a Word document to a 
PCL document, the allegation is nonetheless clearly factually incorrect, in that the 
component responsible for causing the conversion in Schwier is not a "merge utility" 
within the meaning of Claim 1. 

In Schwier, conversion from an original format to a merge format is caused by a 
PCL converter 18. Schwier at FIG. 2; col. 7, 7-9; see also FIG. 9 (illustrating the 
converter as "EMF->PCL Convertor 58"). This converter is not a merge utility. In fact, 
PCL converter 18 functions in the opposite manner of a merge utility, in that PCL 
converter 18 filters or splits a single data stream into multiple data streams. Schwier at 
FIG. 2; col. 7, 7-9. Meanwhile, the only components of Schwier that perform a merger, 
application 10 and printer 7, do not cause or perform any conversion operations. Thus, 
Schwier cannot possibly teach or suggest that a merge utility "caus[es] the second 
document to be converted from the original format to the merge format to create a second 
merge document" as recited in Claim 1. 

B. CLAIM 9 

Dependent Claim 9 recites that "causing the second document to be converted 
from the original format to the merge format to create the second merge document 
includes: . . . passing [a] set of conversion instructions from the merge utility to the first 
document authoring application . . . [that] cause the first document authoring application 
to generate the second merge document based on said set of conversion instructions." 
Thus, Claim 9 teaches that, in response to the merge request recited in Claim 1, a merge 
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utility passes conversion instructions to the document authoring application in which the 
second document was created. These instructions cause the document authoring 
application to convert the second document from the original format to the merge format. 

The FOA alleges that these steps of Claim 9 are taught in Schwier at FIG. 2 and 
column 4, lines 15-20. The FOA is clearly factually erroneous, for at least the reason 
that, while this passage of Schwier may state that an application sends an instruction to a 
PCL convertor 18 to convert a document, PCL convertor 18 is not a "document authoring 
application" in any sense, much less within the meaning recited in Claim 1. That is, 
Claim 1 recites that "the second document was created in [the] original format by [the] 
first document authoring application." Schwier does not teach or suggest that PCL 
convertor 18 was used to create any alleged "original document." 

Moreover, Schwier' s application does not pass the instruction to the PCL 
convertor until after the application has already performed a merge operation, e.g. 
Schwier at FIG. 2, whereas Claim 9 recites that this step occurs as part of converting the 
second document prior to merging the first merge document with the second merge 
document. In other words, the instructions in Schwier are to convert an already combined 
output document, not a single input document as recited in Claim 9. Thus Schwier 
clearly does not teach or suggest the above quoted element of Claim 9. 

C. CLAIM 10 

Claim 10 recites that the request of Claim 1, as discussed above, "contains 
information about the first document authoring application." Claim 10 continues, "the 
merge utility generates], based on the information about the first document authoring 
application, a set of conversion instructions to convert the second document into said 
second merge document." Therefore, the method of Claim 10 recites that a merge utility 
generates conversion instructions based at least upon information about a document 
authoring application that was included in the original merge request. The conversion 
instructions may then be used to cause the conversion of the second document by the 
document authoring application, similar to Claim 9. 

The cited references fail to teach or suggest such a method, for at least the reasons 
that, as explained above, the references fail to teach the merge request of Claim 1 . The 
FOA nonetheless alleges that Schwier' s merge request "contains information about the 
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first document authoring application" because Schwier states in col. 4, lines 25-26, that 
"the referencing is thereby particularly controlled via data that are input via a user 
interface." Clearly, the FOA is in error. This passage has nothing to do with a merge 
request, much less "information about the first document authoring application." Clearly, 
the passage cannot teach or suggest that a merge request "contains information about the 
first document authoring application." 

The FOA further alleges that Schwier teaches that a set of conversion instructions 
is generated "based on the information about the document authoring application" 
included in the merge request because of "the program code or device which enables the 
PCL converter 18 in Figure 2." Again, the FOA is clearly in error. Schwier does not 
teach or suggest that the "program code or device which enables the PCL converter 18" is 
generated "based on the information about the document authoring application" included 
in the merge request. Thus Schwier does not teach or suggest the above quoted elements. 

D. THE REMAINING CLAIMS 

All pending claims not discussed above either depend from, or recite features 
similar to, the claim features discussed above. Therefore, for at least one or more of the 
same reasons discussed above, the rejection as to these remaining pending claims is based 
on one or more clear legal or factual errors. 

III. CONCLUSION 

For at least these above reasons, the Office's rejection of each of the pending 
claims is based on clear legal and factual errors. Accordingly, the cited references fail to 
teach or suggest at least one element of each pending claim. Applicants therefore request 
that the Office remove the current rejection of the pending claims. 

Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 

Date: August 11, 2010 /KarlTRees#58983/ 

Karl T. Rees, Reg. No. 58,983 

2055 Gateway Place, Suite 550 
San Jose, CA 95110 
Voice: (408) 414-1233 
Facsimile: (408)414-1076 
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